Systems and methods for managing and reporting financial information

ABSTRACT

Methods and system consistent with the present invention facilitate the management of financial information. Such methods and systems may receive transaction data, store the transaction data as a line item in a day ledger, receive a request for a report, the request indicating a financial figure, such as an average daily balance, to be generated over a specified time interval, and generate, substantially in real-time or during run-time per the request, a report with the financial figure over the specified time interval using data from the day ledger.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the benefit of priority to U.S. Provisional Patent Application No. 60/554,930, filed on Mar. 22, 2004 and U.S. Provisional Patent Application No. 60/559,017, filed on Aug. 6, 2004, the disclosures of which are expressly incorporated herein by reference, in their entirety.

BACKGROUND OF THE INVENTION

I. Technical Field

The present invention generally relates to methods and systems for managing and/or reporting financial information. More particularly, and without limitation, the invention relates to methods and systems for providing key figures and reports for variable time intervals at run-time using transactional data.

II. Background Information

For many banking and insurance companies, legal requirements (e.g., Federal Reserve regulations in the United States, central or regional bank regulations in Europe, etc.) stipulate that they must provide average balances for various time intervals. In some cases, this is required to establish liquidity. As part of these requirements, they often must generate and store key figures, such as operational balance key figures or average balance key figures. In the case of average balance key figures, they may need to provide average daily balances (ADBs) based on various time intervals, such as week-to-date, month-to-date, quarter-to-date, year-to-date, etc.

Currently, most banks and insurance companies produce these key figures by working from operational data or transactional data. This data may be provided in an On-Line Transaction Processing (OLTP) system. OLTP is a type of computer processing in which the computer responds immediately to user requests. Each request is considered a transaction. OLTP may create transactional data with direct reference to operational processes and business transactions (e.g., customer requests, invoices, goods receipts, etc.). Automatic teller machines for banks are an example of transaction processing systems.

Most banks and insurance companies post-process the transactional data in an OLTP system to generate and store secondary data that provides average balances. This post-processing requires significant investment in software/hardware modifications, such as ABAP program development on OLTP systems like the R/3 ENTERPRISE system from SAP AG in Walldorf, Germany. These modifications may include creating calendar types and daily ledger-like capabilities in a special-purpose ledger (SL) from a general ledger (GL), which for reasons of performance typically stores transaction data only on a monthly basis. The calendar types and the SL provide the ability to interpret end-of-day balances and to keep track of time (e.g., number of days in a time interval, number of days till end of time interval, etc.). Once these modifications are in place, banks and insurance companies may code ADB algorithms to calculate average balances and generate analysis reports including average balance key figures.

Despite these advances, the current capabilities of such post-processing are limited. For example, it is not easy or even possible in some cases to produce reports with both operational balance key figures and average balance key figures, or reports comparing different average balance key figures because the average balance key figures are stored in a rigid, post-processing average balance ledger. As a result, the post-processing is not able to calculate average balance key figures at variable time intervals.

Alternatively, some banks and insurance companies post-process the transactional data by investing in user exit programs to calculate monthly average balances from two SLs, such as a monthly ending balance ledger and an activity average ledger. User exit programs are SAP-defined program objects where the customer can extend the coding to adapt the SAP Standard functionality in a pre-defined way. The calculation takes place during a rollup process and the results are posted to a monthly average balance ledger (i.e., a rollup ledger). This option does not give the required breadth of desired time intervals for ADBs and has performance throughput problems.

Accordingly, it would be beneficial to provide a way to produce key figures and key figure reports in an efficient and flexible manner with minimum database storage and run-time requirements.

SUMMARY OF THE INVENTION

Methods and systems consistent with the present invention may provide many kinds of key figures and reports for variable time intervals at run-time using transactional data. More particularly, methods and systems consistent with the invention may provide different average balance key figures combined with transactional key figures without it being necessary to store separate data for average balances alongside the transactional data. A user may be given the freedom and flexibility to select among the different types of key figures when requesting a report.

One exemplary aspect of the invention relates to a method of managing financial information. The method may comprise receiving transaction data, storing the transaction data as a line item in a day ledger, receiving a request for a report from a user, the request indicating financial figures to be generated over a user-specified time interval, generating, according to the request, the financial figures over the user-specified time interval using data from the day ledger, and providing the report with the generated financial figures. In one embodiment, the request for the report may be entered by a user through an interface, such as a graphical user interface. The request may include characteristics about the items to be included in the report.

Another exemplary aspect of the invention relates to a financial management system. The financial management system may include a processor; and a database, which may be adapted to store transaction data as a line item in a day ledger. The processor may be configured to perform a method comprising receiving a request for a report, the request indicating average daily balance figures to be generated over a specified time interval, and generating, in accordance with the request during run-time, the average daily balance figures over the specified time interval from the day ledger.

Another exemplary aspect of the invention relates to another financial management system. The system may comprise a transaction unit adapted to receive transaction data via a transaction communication channel, a special database connected to the transaction unit, and a reporting unit connected to the special database. The special database may store transaction data as line item data in a day ledger. The reporting unit may provide a report including an aggregate financial figure over a predetermined time interval.

The financial management system may further comprise a general database for storing general ledger information. The general database may be connected to the transaction unit and/or the special database and may be adapted to store aggregated monthly transaction data. The general database may be used to manage accounting data. Having a separate general database may reduce the access time to line item data stored in the special database. Storing line item data related to daily transactions in the special database may decrease the amount of data stored in the general database.

Another exemplary aspect of the invention relates to a computer-readable medium containing instructions to configure a processor to manage financial information. The instructions may configure the processor to receive transaction data, store the transaction data in a database in a day ledger, receive a request for average daily balance key figures, the request indicating a time interval for generating the average daily balance key figures, and generate, substantially in real-time to the receipt of the request, the average daily balance key figures over the time interval using data from the day ledger.

Additional aspects of the invention are set forth in the detailed description which follows or may be learned by practice of methods, systems, and articles of manufacture consistent with the present invention. It is understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several aspects of the invention and together with the description, serve to explain the principles of the invention. In the drawings:

FIG. 1A illustrates an exemplary financial management system environment consistent with the present invention;

FIG. 1B illustrates another exemplary financial management system environment consistent with the present invention;

FIG. 2 illustrates an exemplary information cube for drill-down reporting consistent with the present invention;

FIG. 3 illustrates an exemplary user interface for selecting parameters of a report consistent with the present invention;

FIG. 4 illustrates an exemplary average balance sheet report consistent with the present invention;

FIG. 5 illustrates an exemplary user interface for creating a custom report consistent with the present invention;

FIGS. 6A-6C illustrate exemplary additional user interfaces for creating a custom report consistent with the present invention;

FIG. 7 illustrates an exemplary method of managing financial information consistent with the present invention; and

FIGS. 8A-8F illustrate further exemplary user interfaces for creating a custom report consistent with the present invention.

DETAILED DESCRIPTION

Reference is now made in detail to exemplary aspects of the invention, examples and embodiments of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like parts.

In the embodiments disclosed herein, the generation of financial figures, such as ADB key figures, from transactions in a banking environment for reporting to authorities (such as the Federal Reserve or a central or regional bank authority) are described. Accounting or controlling departments in a bank generally prepare these types of reports. As one of ordinary skill in the art will appreciate, the same or similar analysis and reporting of financial information may also apply to any industry that employs transactional systems. Accordingly, features and principles of the present invention are not limited to the generation of ADB key figures in a banking environment, but are equally applicable to the management of financial information in other industries.

Methods and systems consistent with the present invention may provide various key figures and reports for variable time intervals at run-time or substantially in real-time. In accordance with one embodiment, a system for providing key figures at run-time may include a component to receive and process transaction data, a component to store a SL that accumulates single line items representing transactions in the SL on a daily basis (e.g., a day ledger), and a component to provide reports and views of key figures reflecting the transactions, such as ADBs for variable time intervals. Each line item of the day ledger may represent a posting of a transaction. The system may apply a fiscal year variant with 365 days to the day ledger. From the day ledger, the system may directly calculate relevant key figures “on the fly” and generate drill-down reports containing such figures.

In the banking sector, ADBs may be used for various calculations and other applications. For example, ADBs may be used for customer interest and fee calculations, funds transfer pricing applications, and yield and spread calculations. ADBs may also be used for SEC and regulatory reporting, financial and management reporting, and legal and management consolidations.

Referring now to FIG. 1A, an exemplary financial management system 100 is illustrated. Any suitable combination of hardware, software, and/or firmware may be used to implement the above components. System 100 is exemplary and other systems may comprise the aforementioned financial management system, consistent with features and principles of the present invention.

By way of a non-limiting example, FIG. 1A illustrates an exemplary system environment consistent with the invention. As shown in FIG. 1A, the exemplary system environment may include a number of components, including a transaction processor 102, a database 104, and a drill-down reporting processor 106. These components may be included within financial management system 100 and/or may be owned or operated by a business (e.g., a banking institution) that manages financial data.

Each processor 102 and 106 may include a mainframe, a laptop, a personal computer, a workstation, a computer chip, a digital signal processor board, an analog computer, a plurality of processors, or any other information processing device or combination of devices. Further, each processor 102 and 106 may be implemented by a general-purpose computer or data processor selectively activated or reconfigured by a stored computer program, or may be a specially constructed computing platform for implementing the features and operations disclosed herein. Alternatively, processors 102 and 106 may be the same processor implemented in one of any of the above forms.

As shown in FIG. 1A, financial management system 100 may receive data on transactions over a transaction communication channel 108 from one or more entities or reporting sources 110. For instance, transaction processor 102 may receive data on bank account transactions and other transactions performed by customers and/or other entities 110. An entity may include a corporation, another bank or financial institution, an internal entity, a subsidiary, a third-party procurement department, etc. For banking applications, the transactions may include withdrawals, deposits, transfers, loan acquisitions, payoffs, exchange or transfer of goods, services or funds, or any other dealings between customers and entities 110 and the bank. As will be appreciated by one of ordinary skill in the art, the exemplary system 100 may also be used in connection with other transactional and financial systems.

Transaction communication channel 108 may include a local area network, a wide area network, an intranet, an extranet, the Internet, a telephone network, a wireless network, a wired network, an ATM network, a bank network, a financial network or any other mechanism for communicating transaction information from one location to another.

Transaction processor 102 may process received transactions and store them in database 104. Database 104 may include a hard drive, a tape drive, a RAID disk array, a database system, an optical disk drive, or any other device or system that persistently stores information. For example, transaction processor 102 may execute an accounting interface in R/3 ENTEPRISE software to process posting dates of received transactions and may execute a day ledger interface in R/3 ENTEPRISE software to store the posted transaction in database 104. Transaction processor 102 may store the posted transaction as a line item in a day ledger on database 104 and/or in a month ledger on database 104. Transaction processor 102 may accumulate the line items for each day in the day ledger and store the accumulated daily totals in the day ledger on database 104. Similarly, transaction processor 102 may accumulate the line items for each month and store the accumulated monthly totals in the month ledger on database 104.

Consistent with features and principles of the invention, system 100 may allow one or more users 114, such as bank employees or members of the bank's accounting or controlling department, to access transaction data to generate reports and key figures. For example, drill-down reporting processor 106 may communicate over network 112 with each user 114 and generate reports from the day ledger and/or the month ledger stored on database 104 based on requests received from a user 114. Network 112 may include any mechanism for communicating transaction information from one location to another, including the ones listed above for transaction communication channel 108.

Drill-down reporting processor 106 may generate reports according to parameters provided by users 114. The parameters may include a selection of specific key figures and characteristics from users 114 for the report. Key figures may include an average daily balance and characteristics may include a time interval for the report. For example, drill-down reporting processor 106 may allow a user 114 to request generation of a report for the average daily balance over a user-specified time interval.

FIG. 1B illustrates another embodiment of financial management system 100 consistent with the present invention. Identical reference signs in FIGS. 1A and 1B represent similar elements. Accordingly, system 100 in FIG. 1B includes a transaction processor 102 and a drill-down reporting processor 106. System 100 in FIG. 1B may further comprise a general database 118, a first special database 120A, and/or a second special database 120B. Each of these components may be owned or operated by separate business(es) (e.g., banking institutions) that manage financial data or may be owned by a single entity.

Transaction processor 102 may include an electronic transaction unit adapted to receive transaction data via a transaction communication channel 108. Transaction processor 102 may receive transaction data from a plurality of entities (not shown) connected to system 100 via transaction communication channel 108. General database 118 may store all of the transaction data received by transaction processor 102. Transaction processor 102 may transfer the posted transactions as line items to general ledger database 118. Transaction processor 102 may periodically sum the line items for each month and may store the accumulated monthly totals in a monthly ledger on general database 118. This may reduce the amount of data stored in general database 118 and/or shorten the access time to information on general database 118.

Before transaction processor 102 sums the transaction data stored as line items on general database 118, general database 118 may transfer the transaction data to special databases 120A and/or 120B. Special databases 120A and 120B may respectively receive the transaction data for daily ledger information related to posting dates and value dates. Transaction processor 102 may then sum the line items stored in special databases 120A and/or 120B for each day and store the daily totals for various figures in a day ledger contained in special databases 120A and/or 120B.

For example, transaction processor 102 may store an end-of-day balance, an average balance for the day, and beginning-of-day balance in a day ledger on special databases 120A and/or 120B. Calculating and storing daily totals instead of line items may reduce the amount of data stored in special databases 120A and/or 120B. Similarly, the data on special databases 120A and 120B may be used to calculate year-to-date, month-to-date, and week-to-date average daily balances. The number of days for averaging the transaction data may be chosen without restriction, as long as, special databases 120A and 1208 contain the appropriate daily balance information.

Drill-down reporting processor 106 may generate reports according to additional characteristics selected by the user, such as currency type, company code, account number, business area, profit center, etc. Drill-down reporting processor 106 may allow a user to select characteristics that drills down information available in database 104, 118, 120A, and 120B into a specific report. For example, FIG. 2 illustrates an exemplary information cube for facilitating drill-down reporting, consistent with the present invention. Information cube 202 represents the universe of characteristics that drill-down reporting processor 106 may allow users 114 to select for a report. As shown in FIG. 2, drill-down reporting processor 106 may generate a report 204 with a currency code characteristic (such as U.S. dollar), a profit center characteristic (such as bank branch office or regional office) and a business area characteristic (such as the type of bank accounts or instruments). Although information cube 202 in FIG. 2 is only shown with three dimensions, it may have greater or fewer dimensions. Further, database 104, 118, 120A, and 120B may also use structures other than an information cube (e.g., relational database tables) to store and/or represent the universe of characteristics available for a report.

In one example, drill-down reporting processor 106 may present a user interface for a user to select a report for generation. FIG. 3 illustrates an exemplary user interface 300 presented by drill-down reporting processor 106 for a user 114 to select parameters for a report. Drill-down reporting processor 106 provides characteristics 302 (e.g., currency type, company code, account number, business area, profit center, FIS annual report structure, reporting period, alternative account number, output type, etc.) that each user 114 may select for the report. For example, drill-down reporting processor 106 may receive a selected time interval 304 and type of report structure 306 from a user 114.

Drill-down reporting processor 106 may generate an average balance sheet, such as the exemplary average balance sheet 400 illustrated in FIG. 4, according to characteristics 302 (cf. FIG. 3) entered or selected by a user 114. As part of average balance sheet 400, drill-down reporting processor 106 may provide average daily balances 402 for a time interval 404. Drill-down reporting processor 106 may generate average daily balances 402 for items 406 from the daily ledger stored in database 104 (cf. FIG. 1A) or in special database 120A and 120B (cf. FIG. 1B). Further, drill-down reporting processor 106 may provide period balances 408 and accumulated balances 410 for items 406. For example and as illustrated in FIG. 4, drill-down reporting processor 106 may generate ADBs 402, period balances 408, and/or accumulated balances 410 for bank assets (e.g., cash and due from bank, total securities, trading assets at fair value, federal funds sold and securities purchased under resale agreement, loans, premises and equipment, accrued interest receivable, other assets, etc.), liabilities and shareholder equity (e.g., total liabilities, total shareholder's equity, etc.), and income statements (e.g., net income, income before taxes, etc.).

In accordance with one embodiment, drill-down reporting processor 106 may generate ADBs 402 by summing end-of-day balances and dividing the sum by the total number of days in a time interval. In other words, drill-down reporting processor 106 may calculate ADBs 402 by adding posted activities in an account from each day of a time interval (daily, monthly, quarterly, etc.) and dividing that figure by the total number of days in the time interval. Therefore, ADB is a function of aggregate balance of the time interval and the number of days in the time interval.

For example, drill-down reporting processor 106 may generate ADBs 402 according to the following:

${ADB} = \frac{AGB}{NOD}$

where AGB is the aggregate balance over time interval 404, and NOD is the number of days in time interval 404. Drill-down reporting processor 106 may calculate the AGB by summing every end-of-day balance in the day ledger over a time interval, as shown below;

${AGB} = {\sum\limits_{t \Subset T}\; {EoDB}_{t}}$

where EoDB_(t) is the end-of-day balance for day t, and T is the set of days within time interval 404. Drill-down reporting processor 106 may use the posting dates or cash dates of transactions as the baseline dates for determining the AGB, NOD, and ADB.

Alternatively, drill-down reporting processor 106 may compute the aggregate balance by adding the AGB of the previous day to the current days end-of-day balance:

AGB_(t)=AGB_(t−1)+EoDB_(t)

where AGB_(t) is aggregate balance at day t, AGB_(t−1) is the aggregate balance at day (t−1), and AGB_(t) at t=1 is the end-of-day balance for the first day of time interval 404.

Daily transaction postings to ledger accounts impact not only the end-of-day balance at the posting date, but also the end-of-day balances of future dates. Further, daily transaction postings affect the end-of-day balance of a transaction's current period (e.g., month in which transaction was posted), as well as all future periods (e.g., quarter or year in which transaction was posted). For example, the beginning balance for an account in January may be 100 dollars. Accordingly, drill-down reporting processor 106 may set the daily balances and monthly balances for all days and months of the year to 100 dollars. The logic is that, unless there is activity in this account, the balances remains the same and does not need to be updated. Following that logic (and in it's simplest form), drill-down reporting processor 106 may calculate the aggregate balance for each month by multiplying the beginning balance by the number of the days in the month: The January aggregate balance would be 3100 dollars, the February aggregate would be 2800 dollars (2900 dollars in a leap year), etc. Therefore, when each month's aggregate balance is divided by its respective number of the days in the month, the result is 100 dollars. Since there has not been any activity to the account, this is a correct ADB and drill-down reporting processor 106 will correctly project the balance for each day of the month to be 100 dollars.

As can be seen in the above example, one aspect of the ADB calculation is to determine the number of days in the time interval affected by a posting activity, whereby a banking calendar time interval could encompass a day, a month, a week, a quarter, a year, etc. The drill-down reporting processor 106 must be aware of the implications due to the different calendar times and apply the correct number of days for any chosen time interval. Therefore, to fulfill the ADB requirements the GL and the drill-down reporting processor 106 must be calendar aware.

For the sake of demonstration, let us continue the example above and assume a credit to the balance sheet account of 70 dollars on January 23^(rd). This activity posting would reduce the daily balance of 100 dollars to 30 dollars as of January 23^(rd) and all subsequent days of the year, but would not affect the daily balances prior to January 23^(rd). On January 23^(rd), drill-down reporting processor 106 may determine the number of days affected by the posting activity, which would be one day (on January 31^(st), it would be nine days). This number of days is multiplied by the amount of activity and added to the aggregate balance. For example, on January 23^(rd), the aggregate balance up to that day would be given by:

$\begin{matrix} {{AGB}_{Jan23} = {{AGB}_{Jan22} + {EoDB}_{Jan23}}} \\ {= {2200 + \left( {100 - 70} \right)}} \\ {= 2230} \end{matrix}$

which yields an ADB of 96.96 dollars for the first 23 days in January (i.e., month-to-date). On January 31^(st), the aggregate balance up to that day would be given by:

$\begin{matrix} {{AGB}_{Jan31} = {{AGB}_{Jan22} + {\sum\limits_{t = {Jan23}}^{t = {Jan31}}\; {EoDB}_{t}}}} \\ {= {2200 + {9 \times \left( {100 - 70} \right)}}} \\ {= 2470} \end{matrix}$

which yields an ADB of 79.68 dollars for the 31 days in January. Note that for all subsequent months, all of the daily balances are also affected. For example, on March 31^(st), the aggregate balance is 930 dollars, which yields an ADB of 30 dollars for the 31 days in March.

Further, the ADB for the quarter-to-date and year-to-date on March 31^(st) would both be 47.11 dollars for the 90 days (31 days in January plus 28 days in February plus 31 days in March). In summary, today's ADB is the balance equal to today's aggregate balance divided by the number of days in the period-to-date, whereby aggregate balance is the total result of today's end-of-day balance (i.e., net balance of total credits and debits of the day) plus the prior period's aggregate balance.

Consistent with the present invention, system 100 may provide an interface for a user to create custom reports. For example, drill-down reporting processor 106 may present a user interface, such as the exemplary user interface 500 illustrated in FIG. 5, to employee 114. Drill-down reporting processor 106 may receive data from a user 114 reflecting a form type 502, a form name 504, and/or a structure 506 for a custom report. Next, drill-down reporting processor 106 may present one or more additional interfaces, such as the exemplary user interface 600 illustrated in FIGS. 6A-6C, to user 114 to allow him/her to select and define the key figures 602 that he/she wishes to include in the custom report. In this example, a user 114 has chosen to include in the report, average daily balance key figures for three time intervals (e.g., year-to-date, quarter-to-date, and month-to-date). Drill-down reporting processor 106 may save the custom report from user 114 as a template for later use by user 114 or others.

Consistent with an embodiment of the invention, system 100 may perform a method of managing financial information, such as the exemplary method illustrated in FIG. 7. As shown in FIG. 7, transaction processor 102 may receive transaction data from a customer or entity 110 (block 702). Transaction processor 102 may receive transaction data from one or more customers or entities 110 via, for example, transaction communication channel 108. Transaction processor 102 may store received transaction data as a line item in a day ledger (block 704). Steps 702 and 704 may be performed periodically (e.g., once a day, once a week, etc.).

As discussed above, based on input from a user, drill-down reporting processor 106 may generate average daily balance(s) over one or more time intervals from the day ledger (block 706). Drill-down reporting processor 106 may generate a report including the average daily balance(s) specified by the user (block 708). The report may provide a comparison of the average daily balance over the time interval with another average daily balance over a different time interval. Drill-down reporting processor 106 may perform blocks 706 and 708 on demand in real-time or at run-time (e.g., whenever a request for a report or an average daily balance is made by a user).

For example, in one exemplary embodiment consistent with the invention, transaction processor 102 (FIG. 1A) may execute SAP R/3 ENTERPRISE software, including an R/3 accounting interface and R/3 special ledger interface. The R/3 ENTERPRISE software may receive transactional information, and may store the transactional information in a totals table and a line items table of a day ledger on database 104, or on databases 118, 120A, and 120B. The totals table may include the summed line items for each day. Further, drill-down processor 106 may execute SAP R/3 ENTERPRISE EXTENSION SET 2.0 software to allow a user to create custom reports for the display of ADBs. The custom reports may be based on forms. Exemplary custom reports may include the reports shown in FIGS. 4 and 6A.

By way of example, FIG. 8A illustrates an initial user interface that drill-down processor may present to a user to create a custom “Transaction Figures on a Daily Basis” report 802 based on an ADBREPORT-1 form 804. The ADBREPORT-1 form may have general characteristics, such as “Ledger” (RLNDR), “Record Type” (RRCTY), and “Version” (RVERS). RLNDR is a specified day ledger that stores the data for ADB reporting, RRCTY is a characteristic indicating whether the data should be actual data or planned data. RVERS is a characteristic used to select the version of planned data. The planned data and actual data may be different. The general characteristics may be set with fixed values.

Drill-down processor 106 may provide tab pages with options for specific characteristics (e.g., characteristics 806, variables 808, output type 810, and options 812) configured to be selectable by a user when drill-down processor 106 executes the custom “Transaction Figures on a Daily Basis” report. As illustrated in FIG. 8B, characteristics 806 may include “currency type,” “currency,” “Balance Sheet/Profit and Loss (BS/P&L) item/account,” “account number,” “company code,” etc. The BS/P&L structure may be a hierarchical tree with different notes and accounts on its leaves, and may define the logical structure of the ADB report. When creating the custom report, drill-down processor 106 may allow the user to indicate whether each of characteristics 806 should be based on information from a financial statement, based on a hierarchy, such as a BS/P&L tree, or no hierarchy, or entered during execution of the custom report, as illustrated in FIG. 8C.

Drill-down processor 106 may also allow the user to indicate whether any values for variables 808 should be entered during execution of the custom report. Variables 808 may include an “FIS Annual Reporting Structure,” an “ADB Period To,” etc., as illustrated in FIG. 8D. Drill-down processor 106 may also allow the user to specify an output type 810 for the custom report. Output types 810 may include a graphical report, classic drill-down, object list, or spreadsheet, as illustrated in FIG. 8E. Drill-down processor 106 may allow the user to configure output type 810 to be available for selection when executing the custom report.

After the user creates the custom report, the user may have drill-down processor 106 save the custom report. Drill-down processor 106 may later retrieve and execute the saved custom report. Upon execution, drill-down processor 106 may present characteristics of the custom report that have been configured for selection to a user, as illustrated in FIG. 8F. The user may enter his/her choices and information for the characteristics, and drill-down processor 106 may generate an ADB report, such as average balance sheet 400 illustrated in FIG. 4, for “Transaction Figures on a Daily Basis,” according to the entered choices and information.

One of ordinary skill in the art will appreciate that features and principles of the present invention may be implemented in a computer-readable medium (e.g., floppy disk, CD-ROM, storage device, etc.) containing instructions for a system, such as financial management system 100, to execute the instructions.

The embodiments and aspects of the invention set forth above are only exemplary and explanatory. They are not restrictive of the invention as claimed. Other embodiments consistent with features and principles are included in the scope of the present invention.

In the foregoing description, various features are grouped together for purposes of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following sample claims reflect, inventive aspects may lie in fewer than all features of a single foregoing disclosed embodiment. Thus, the following claims are hereby incorporated into this description, with each claim standing on its own as a separate embodiment of the invention. 

1.-39. (canceled)
 40. A computer-implemented method for generating customized financial reports, the method comprising: receiving data including line items indicative of transactions performed by customers; storing, in a database, the received data; periodically generating, with at least one processor, an end-of-period balance by accumulating the line items over a predetermined time period; determining a change in the end-of-period balance caused by a specific transaction posted by the customers; determining time periods affected by the change in the end-of-period balance; adjusting, with the at least one processor, end-of-period balances corresponding to the affected time periods according to the change in the end-of-period balance; updating the data stored in the database with the adjusted end-of-period balances; receiving a request for a report from a user, the request indicating key figures and characteristics selected by the user; and generating the report based on the data stored in the database according to the key figures and characteristics selected by the user.
 41. The method of claim 40, wherein the predetermined time period is one of a day, a week, a month, a quarter, or a year.
 42. The method of claim 40, wherein the affected time periods are later in time than the specific transaction posted by the customers.
 43. The method of claim 40, wherein the key figures include at least an average balance and the characteristics include a user-specified time interval.
 44. The method of claim 43, further comprising: calculating the average balance by dividing an aggregate balance over the user-specified time interval by a number of time periods in the user-specified time interval.
 45. The method of claim 44, wherein generating the report comprises providing a comparison of the average balance over the user-specified time interval with an average daily balance over a different time interval.
 46. The method of claim 44, further comprising adjusting the aggregate balance over the user-specified time interval according to the change in the end-of-period balance.
 47. The method of claim 46, further comprising determining a beginning-of-period balance for the predetermined time period.
 48. The method of claim 47, further comprising storing the end-of-period balances, the average balance, and the beginning-of-period balance without the line items in a database.
 49. The method of claim 40, wherein the report is generated in substantially real time.
 50. The method of claim 40, wherein the characteristics further include one or more of a currency type, a business entity, an account number, or a business area selected by the user.
 51. The method of claim 40, wherein the request further indicates one or more of a form type, a form name, a structure, or an output type selected by the user for the report.
 52. The method of claim 51, wherein the structure is a hierarchical structure.
 53. The method of claim 52, wherein the hierarchical structure includes a plurality of notes and leaves, the leaves being associated with a plurality of accounts.
 54. The method of claim 51, wherein the output type indicates at least one of a graphical report, a classic drill-down report, an object list report, or a spreadsheet report.
 55. A system for generating customized financial reports, comprising: a tangible storage medium that stores instructions; a processor that executes at least part of the instructions to: receive data including line items indicative of transactions performed by customers; store, in a database, the received data; periodically generate an end-of-period balance by accumulating the line items over a predetermined time period; determine a change in the end-of-period balance caused by a specific transaction posted by the customers; determine time periods affected by the change in the end-of-period balance; adjust end-of-period balances corresponding to the affected time periods according to the change in the end-of-period balance; and update the data stored in the database with the adjusted end-of-period balances; and receive a request for a report from a user, the request indicating key figures and characteristics selected by the user; and generate the report based on the data stored in the database according to the key figures and characteristics selected by the user.
 56. The system of claim 55, wherein the request further indicates one or more of a form type, a form name, a structure, or an output type selected by the user for the report.
 57. The system of claim 56, wherein the structure is a tree structure including a plurality of notes and leaves, the leaves being associated with a plurality of accounts
 58. A non-transitory computer-readable medium including instructions, which, when executed by at least one processor, cause the at least one processor to perform a method for generating customized financial reports, the method comprising: receiving data including line items indicative of transactions performed by customers; storing, in a database, the received data; periodically generating an end-of-period balance by accumulating the line items over a predetermined time period; determining a change in the end-of-period balance caused by a specific transaction posted by the customers; determining time periods affected by the change in the end-of-period balance; adjusting end-of-period balances corresponding to the affected time periods according to the change in the end-of-period balance; updating the data stored in the database with the adjusted end-of-period balances; receiving a request for a report from a user, the request indicating key figures and characteristics selected by the user; and generating the report based on the data stored in the database according to the key figures and characteristics selected by the user.
 59. The computer-readable medium of claim 58, wherein the request further indicates one or more of a form type, a form name, a structure, or an output type selected by the user for the report. 